Machine learning engine for demand-based pricing

ABSTRACT

Systems, methods and products for determining a consumer-facing price using a demand model that is generated based on historical transactional data. One embodiment comprises a method implemented in a pricing module of an automotive data processing system. Data that identifies a consumer (or consumer group) and a vehicle type are received and the demand model is accessed to generate a payment corresponding to the attributes of the consumer and the attributes of the vehicle type. The demand model may be implemented in a machine learning engine that maintains a set of weights β used in a predictive demand function. The weights are adjusted by the machine learning engine to minimize a loss function which measures deviation of demand estimated by the predictive demand function from the demand indicated by a set of historical transaction data.

RELATED APPLICATIONS

This application is a continuation of, and claims a benefit of priorityunder 35 U.S.C. 120 of, U.S. patent application Ser. No. 16/914,208filed Jun. 26, 2020, entitled “MACHINE LEARNING ENGINE FOR DEMAND-BASEDPRICING,” which claims priority under 35 U.S.C. § 119(e) to U.S.Provisional Patent Application No. 62/868,535 filed Jun. 28, 2019,entitled “PAYMENT-DRIVEN SOURCING”, and U.S. Provisional PatentApplication No. 62/883,374 filed Aug. 6, 2019, entitled “DEMAND-BASEDPRICING”, which are fully incorporated herein by reference for allpurposes.

TECHNICAL FIELD

The present disclosure relates generally to the field of data processingsystems and methods, and more particularly to data processing systemsand methods that determine a payment that is associated with a consumerprofile based on historical transaction data.

BACKGROUND

Internet-based systems and other computer systems that facilitatepurchasing (buying or leasing) various goods and services from multiplesellers have become increasingly popular tools for both consumers andsellers. Intermediary search sites allow users to search for items suchas vehicles from a large number of available items. When a user selectsa vehicle, the intermediary site typically puts the buyer in touch withthe dealer to finalize the transaction. The consumer may schedule a testdrive with the dealership and may thereafter choose to lease thevehicle. In order to complete the lease transaction, the lease paymentsand the residual value of the vehicle must typically be determined.

In many conventional internet-based systems for facilitating vehiclepurchase or lease transactions, the operators of these systems may becaught in the middle between sellers that want to get high prices fortheir vehicles and consumers who want to obtain the vehicles at thelowest possible price. The system operator's costs to operate the systemand facilitate the transactions may be constrained by the competinginterests of the sellers and consumers, so that it is not profitable (ornot as profitable as desired) to provide their services in facilitatingthe transactions. It may therefore be desirable to provide systems andmethods for enabling system operators to determine pricing for vehiclessuch that the operator's business constraints are met.

SUMMARY

Conventional systems do not provide the ability to source the vehicles(purchase them from sellers) in a way that ensures that the systemachieves a desired return on the transactions. Embodiments of thepresent invention may enable sales or lease transactions of inventoryitems such as vehicles, where the items may be acquired and sold/leasedat prices which meet a system operator's business goals as well as aconsumer's payment needs.

Systems and methods disclosed herein use information relating topayments by the consumer (e.g., likelihood of converting a transaction),as well as information relating to the system operator's services (e.g.,a required level of profitability) to determine which of a seller'sproducts meet the constraints associated with both the consumer and thesystem operator. The system operator can then acquire these products andpresent them to the consumer with confidence that the system operator'sown requirements, such as a desired net return, can be met. The presentsystems and methods may process very large quantities of data to enablethe system operator to accurately determine the interest of particularconsumers in specific types of vehicles, as well as the likelihood thatthese consumers will transact on the vehicles, thereby allowing thesystem to be operated to meet the desired goals. By enabling theaccurate determination of consumer interest and propensity to transact,the system may also enable the system operator to determine prices atwhich vehicles can be profitably acquired.

The present disclosure describes a module (which may be referred toherein as a demand module or a pricing module) that implements a demandmodel to determine a consumer-facing price which will be likely toresult in a desired conversion rate, given some set of inputs relatingto a particular consumer of interest and a particular product ofinterest. The consumer-facing price may be determined without regard tothe price for a vehicle set by a seller. The consumer-facing price maybe used in conjunction with expense information (e.g., costs associatedwith acquiring the vehicle and operating the system) and informationregarding business goals (e.g., a desired rate of return) to determine atarget vehicle acquisition price. This target price can be compared toprices which are set by the sellers for their respective vehicles inorder to determine which of the vehicles will, if presented toconsumers, meet the business goals of the system operator.

In some embodiments, the system implements a demand model that uses verylarge quantities of historical sales transaction data (essentially allrelevant data available from the automotive marketplace) to determinethe demand for a particular type of vehicle with respect to a particulartype of consumer. The type or profile of the consumer may be anidentified segment of the consumer population having characteristics orattributes that fall within predefined ranges. The “type” of vehicle maybe defined by characteristics or attributes that are commonly used todistinguish or classify vehicles, such as the make, model and year ofthe vehicle. The consumer types and vehicle types may have varyinglevels of granularity in different embodiments, with increasinggranularity generally allowing for greater detail and accuracy, but atgreater cost (in expense, processing resources and time). Based on thehistorical data, the demand module can determine how much a given typeof consumer is willing to pay for a given type of vehicle.

Embodiments of the invention may include systems, methods and productswhich determine a consumer-facing price based on collected transactionaldata. For example, one embodiment is a method for collecting andprocessing consumer transaction information, generating a demand model,and using the demand model to determine vehicle pricing. This methodincludes receiving data identifying a first one of a plurality ofconsumer groups and a first one of a plurality of vehicle types,accessing a demand model that defines a corresponding payment for eachof a plurality of combinations of the plurality of consumer groups andthe plurality of vehicle types, and generating a first paymentcorresponding to the first one of the plurality of consumer groups andthe first one of the plurality of vehicle types. Each of these steps areperformed in this embodiment by a pricing module of the automotive dataprocessing system. In one embodiment, the demand model comprises amachine learning engine which is configured to maintain a set of weightsβ that are included in a predictive demand function of the demand model.The weights may include, for example, include a price weight β_(m), aconsumer attribute weight β_(U), and a vehicle attribute weight β_(V),where some of the weights (e.g., consumer attribute weight β_(U) and avehicle attribute weight β_(V)) may comprise vector weights that canindependently weight different attributes of the user profile and/orvehicle type. The machine learning engine is configured to adjust theweights to minimize a loss function which measures deviation of demandestimated by the predictive demand function from actual demand indicatedby a set of historical transaction data. The historical transaction datamay be obtained, for example, from sources external to the automotivedata processing system, or it may be collected by tracking and storingthe browsing and/or search activities of users of the automotive dataprocessing system.

In one embodiment, the predictive demand function comprises a functiond(m,

,

), where

${{d\left( {m,\overset{\rightharpoonup}{U},\overset{\rightharpoonup}{V}} \right)} = \frac{1}{1 + {\exp\left( {\beta_{0} + {\beta_{m} \cdot m} + {{\overset{\rightarrow}{\beta}}_{U} \cdot \overset{\rightharpoonup}{U}} + {{\overset{\rightarrow}{\beta}}_{V} \cdot \overset{\rightharpoonup}{V}} + {{\overset{\rightarrow}{\beta}}_{\overset{\rightharpoonup}{U} \otimes \overset{\rightharpoonup}{V}} \cdot \left( {\overset{\rightharpoonup}{U} \otimes \overset{\rightharpoonup}{V}} \right)}} \right)}}},$

and where ⊗ represents the Kronecker product, m represents a consumerfacing price,

represents a set of consumer attributes, and

represents a set of vehicle attributes. Since this function relatesdemand to the consumer facing price, consumer attributes and vehicleattributes, it can be used to generate a demand model from which theconsumer facing price can be determined, given the demand and consumerand vehicle attributes. In another embodiment, the predictive demandfunction comprises a stratified function such as

${d\left( {m,\overset{\rightharpoonup}{U},\overset{\rightharpoonup}{V}} \right)} = \left\{ {\begin{matrix}\frac{1}{1 + {\exp\left( {\beta_{0,1} + {\beta_{m,1} \cdot m} + {{\overset{\rightarrow}{\beta}}_{V,1} \cdot \overset{\rightharpoonup}{V}}} \right)}} & {\overset{\rightharpoonup}{U}\mspace{14mu}{in}\mspace{14mu}{Group}\mspace{14mu} 1} \\\frac{1}{1 + {\exp\left( {\beta_{0,2} + {\beta_{m,2} \cdot m} + {{\overset{\rightarrow}{\beta}}_{V,2} \cdot \overset{\rightharpoonup}{V}}} \right)}} & {\overset{\rightharpoonup}{U}\mspace{14mu}{in}\mspace{14mu}{Group}\mspace{14mu} 2} \\\frac{1}{1 + {\exp\left( {\beta_{0,3} + {\beta_{m,3} \cdot m} + {{\overset{\rightarrow}{\beta}}_{V,3} \cdot \overset{\rightharpoonup}{V}}} \right)}} & {\overset{\rightharpoonup}{U}\mspace{14mu}{in}\mspace{14mu}{Group}\mspace{14mu} 3}\end{matrix},} \right.$

where m represents a consumer facing price,

represents a set of consumer attributes, and

represents a set of vehicle attributes.

In one embodiment, the demand model measures a conditional conversionprobability which indicates a target probability that a consumer withconsumer attributes

will transact on an offer for a particular vehicle having vehicleattributes

through a search function of the automotive data processing system. Inanother embodiment, the demand model measures a vehicle velocityprobability which indicates a target probability that the consumer willtransact on an offer for the vehicle within a predetermined time period(e.g., two weeks) from the particular vehicle becoming available throughthe automotive data processing system. In another embodiment, the demandmodel measures a click-through rate which indicates a rate at whichconsumers with consumer attributes

will select vehicles having vehicle attributes

through a viewing function of the automotive data processing system.

Another embodiment may be a computer-based system that enables consumersto interact with an automotive data processing system from theirpersonal computing devices (e.g., smart phones or laptops) via anetwork, where the automotive data processing system collectstransactional data from the users and generates a demand model that isused to determine pricing for vehicles corresponding to desired businessgoals (e.g., conversion rate).

Another embodiment may be a computer program product comprising acomputer-readable medium that contains instructions executable by acomputing device to perform a method for collecting and processingconsumer transaction information to generate a demand model which isused to determine vehicle pricing based on a given consumer type andvehicle type.

Many other alternative embodiments may also be possible.

BRIEF DESCRIPTION OF THE FIGURES

The drawings accompanying and forming part of this specification areincluded to depict certain aspects of the invention. A clearerimpression of the invention, and of the components and operation ofsystems provided with the invention, will become more readily apparentby referring to the exemplary, and therefore non-limiting, embodimentsillustrated in the drawings, wherein identical reference numeralsdesignate the same components. Note that the features illustrated in thedrawings are not necessarily drawn to scale.

FIG. 1 is a high level block diagram of one embodiment of a networktopology.

FIG. 2 is a diagram illustrating the operation of an automotive dataprocessing system to generate a consumer payment for a vehicle inaccordance with one embodiment.

FIG. 3 is a flow diagram illustrating the generation of a consumerpayment for a vehicle in accordance with one embodiment.

FIG. 4 is a flow diagram illustrating a method for generating a demandmodel in accordance with some embodiments.

FIG. 5 is a flow diagram illustrating the use of a list of qualifiedvehicles to generate displays responsive to a consumer having a givenprofile in accordance with one embodiment.

FIG. 6 is a diagrammatic representation of a distributed networkcomputing environment in which some embodiments may be implemented.

DETAILED DESCRIPTION

The invention and various features and advantageous details thereof areexplained more fully with reference to the exemplary, and thereforenon-limiting, embodiments illustrated in the accompanying drawings anddetailed in the following description and appendices. It should beunderstood, however, that the detailed description and the specificexamples, while indicating the preferred embodiments, are given by wayof illustration only and not by way of limitation. Descriptions of knownprogramming techniques, computer software, hardware, operating platformsand protocols may be omitted so as not to unnecessarily obscure thedisclosure in detail. Various substitutions, modifications, additionsand/or rearrangements within the spirit and/or scope of the underlyinginventive concept will become apparent to those skilled in the art fromthis disclosure.

The present disclosure is directed to systems, methods and products forgenerating and using a demand model that determines, based on aspecified consumer type and an identified vehicle type, a payment thatresults in a desired business goal, such as a target conversion rate.The demand model uses historical sales transaction data which iscollected and analyzed to determine demand relationships betweenconsumers and vehicles. The historical transaction data may includeessentially all of the relevant data that is available from theautomotive marketplace. The demand model is used in an automotive dataprocessing system to identify, for a specific consumer in relation to aspecific vehicle type, a payment that corresponds to a desiredlikelihood of the consumer completing a transaction with respect to theidentified type of vehicle. This payment may be used, for example, byproviding it to a cashflow model which uses this information, along withinformation such as a desired return on a transaction for the identifiedtype of vehicle, to generate an acquisition target price that is used toqualify vehicles for display to the consumer. In this manner, the use ofthe demand model enables the system to eliminate vehicles andcorresponding transactions that would not be likely to meet the goals ofboth the consumer and the system operator, making the system moreefficient than conventional systems used in vehicle sales transactions.

In some embodiments, the demand model is implemented in the context ofan automotive data processing system that is configured to interact withconsumers and vehicle sellers (e.g., automotive dealerships) via clientapplications running on the respective client devices of the users.These systems enable sellers to present vehicles that are available forpurchase or lease to consumers. The sellers set purchase prices for thevehicles that are available through the system, and consumers may viewthe vehicles, potentially choosing to lease one of the viewed vehiclesthrough the system. If this is the case, the automotive data processingsystem may perform various processing to facilitate the consumer's leaseof the vehicle. In some embodiments, if the consumer wishes to proceedwith the lease transaction, a selected vehicle is purchased by theautomotive data processing system operator and the vehicle is thenleased to the consumer. It should be noted that, although the systemsand methods described herein focus on the leasing of vehicles toconsumers, the demand model should be broadly construed and may be usedin other embodiments that involve vehicle purchases, or the leasing orpurchase of other types of items.

The system operator is compensated for the services that are provided inassociation with the lease transaction(s) by pricing the vehicle leaseto the consumer at a level which is high enough that it is expected tocover the price at which the vehicle was purchased from the originalseller and the associated costs (e.g., cost of capital, marketing,origination, servicing, depreciation, liquidation) and a net return,less the residual value. It is desirable for the operator of theautomotive data processing system to be able to ensure that theacquisition price (the price at which the vehicle is required from theoriginal seller) is low enough that the system operator makes a desiredreturn on the vehicle. Because the vehicle seller, rather than thesystem operator, sets the price at which the vehicle may be acquired bythe system operator, the system operator conventionally has no controlover this price. The present systems, however, provide means such as thedemand model which enable the system to be operated in a way thatensures the consumer payment and vehicle acquisition price are withinranges that achieve the desired return for the system operator onvehicles purchased using the system.

These systems effectively achieve control of the acquisition prices ofvehicles that may be purchased by consumers by determining the paymentsthat can be made by consumers, determining the desired return on thesystem operators investment in the purchased vehicles, determining theacquisition price that is necessary to achieve the desired return, andlimiting the vehicles that are available through the system to onlythose which are priced to provide the desired return. The systems use ademand model to determine the payment corresponding to a particular typeof consumer and a particular type of vehicle.

As mentioned above, the demand model is intended to identify a paymentat which a consumer having a particular profile is likely to complete apurchase transaction for a vehicle of a given type. In one embodiment,the demand model is developed by examining portions of this transactiondata corresponding to particular combinations of consumer profile andvehicle type. The consumer profile may be defined by any suitable set ofvalues for a defined set of factors that might potentially drive therate of default or return (e.g., FICO score, income, payment-to-incomeratio, loan-to-value ratio, down payment amount, recurring monthlypayment amount, depreciation, Vehicle Year Make Model Miles, vehiclevalue, origination location, origination channel (rideshare/consumer),etc.). The vehicle type may be defined by factors such as make andmodel, or make, model and year.

The interest level of consumers with a particular profile in aparticular type of vehicle may be determined in a number of ways. In oneembodiment, for each combination of consumer profile and vehicle type,the corresponding records in the historical transaction data can beranked according to the associated purchase prices. Then, a target priceis determined by identifying the price corresponding to a specificpercentile of the completed transactions. For example, the 5thpercentile may correspond to a target price of $400. Thus, 5% of theconsumers that fall within the identified consumer profile will completea purchase for a vehicle of the identified type if the purchase price is$400. The selected percentile may be increased or decreased, which mayin turn affect the pace at which vehicles are purchased through theapplication. For instance, if a greater percentile is selected (e.g., 6%instead of 5%), the target price will be slightly lower, reflecting thegreater number of purchasers at the target price.

In some embodiments, consumer interest may be determined based on aconversion rate. For a given consumer type, the rate at which consumersof that type convert (complete a transaction on a vehicle) will varywith the payment on the particular type of vehicle. Higher payments willnormally correspond to lower conversion rates, while lower payments willcorrespond to higher conversion rates. A payment can be selected bychoosing a desired conversion rate and selecting the payment thatcorresponds to the chosen conversion rate. The conversion rate can beused to select a payment (a simple dollar amount) or a percentage of thevehicle value.

In another embodiment, the level of the consumer's interest can bedetermined by examining the historical transaction data to determine thelikelihood that a vehicle which has been made available through thesystem for some period of time has been the subject of a transaction(the “vehicle velocity”). For instance, it may be determined whatpercentage of vehicles of a certain type have been the subject of atransaction when they have been available for two weeks or less. Thispercentage may be determined as a function of the payments associatedwith the vehicles. Generally, as the payment increases, the percentageof vehicles that are transacted within the chosen period of time willdecrease, reflecting lower consumer interest at the higher paymentlevel.

In another embodiment, the level of the consumer's interest can bedetermined by examining data that is collected on the consumers' directinteractions with the system. As consumers browse the vehicles that areavailable through the system, they will click on vehicles (selectlistings corresponding to the vehicle) that are of interest in order toview more detailed information on the vehicles. When a consumer clickson a particular vehicle, this action is recorded by the system, and a“click-through” rate can be determined for each vehicle. Vehicles thatgenerate higher levels of interest will have higher click-through rates.The system can then determine the click-through rate for a particularvehicle type as a function of the payment level for the vehicle type. Asthe payment level for the vehicle increases, the click-through rate willgenerally decrease. The system can therefore select a payment for avehicle type that will produce a desired click-through rate.

Whichever type of analysis is used, a similar analysis is performed foreach combination of consumer profile and vehicle type. Thus, for eachcombination of these inputs (i.e., a given consumer profile and a givenvehicle type), the demand model can provide a corresponding targetprice, based on the selected percentile of transactions to be converted,vehicle velocity, click-through rate, etc.

The payment determined by the demand model is provided, along with adesired return, to a cash flow model which determines a requiredacquisition price for that type of vehicle which is necessary to ensurethe desired return if a consumer make the identified payment for thevehicle. The computed acquisition price can then be compared to vehiclesof this type which have been made available by sellers through thesystem. Available vehicles which have prices at or below the acquisitionprice may be displayed to consumers (potential purchasers of thevehicles), while available vehicles that have prices above theacquisition price are not displayed. Thus, it will be assured that anypurchase transaction that may be completed through the system willprovide the desired return on the acquisition cost.

Data processing systems incorporating the disclosed demand model mayautomate and facilitate purchase processes, including inventoryselection, financing qualification and document generation. In anexemplary embodiment, the system facilitates selection of a vehicle byproviding vehicle information to a consumer through an interface on amobile device. In this context, a “consumer” is any individual, group ofindividuals, or business entity seeking to purchase a vehicle (or otherasset) through the system. The consumer may select a particular vehiclethat is used as the basis for determining similarity (i.e., the othervehicles are compared to the selected vehicle). The similarity scoresare used to identify vehicles similar to the consumer-selected vehicle,and the similar vehicles are presented to the consumer to facilitate theconsumer's search for a vehicle that the consumer may wish to purchase.

Some embodiments of a system for facilitating transactions may beimplemented in a network topology. FIG. 1 is a high level block diagramof one embodiment of an example topology. The network topology of FIG. 1comprises an automotive data processing system 100 which is coupledthrough network 105 to client computing devices 110 (e.g. computersystems, personal data assistants, smart phones or other clientcomputing devices). Network 105 may be, for example, a wireless orwireline communication network such as the Internet or wide area network(WAN), publicly switched telephone network (PSTN) or any other type ofcommunication link. The system may further include one or moreinformation provider systems 120, one or more dealer management systems(DMS) 122, inventory systems 124, department of motor vehicles (DMV)systems 126 or other systems.

Automotive data processing system 100 may provide a comprehensivecomputer system for automating and facilitating a purchase processincluding inventory selection, financing qualification, documentgeneration and transaction finalization, as described in detail in U.S.Patent Application Pub. No. 2018/0204281, which is hereby incorporatedby reference. The present disclosure focuses primarily on aspects of thesystem involving inventory selection, and more particularly componentsof the system relating to the ranking of displayed inventory items, thetracking of user actions associated with the displayed inventory items,and tuning of the ranking engine that generates the ranking of thedisplayed inventory items.

Using a client application 114 executing on a client device 110, aconsumer user may search dealer inventory, apply for financing, select avehicle of interest from a dealer and review and execute documentsrelated to the purchase of the vehicle, and execute automated clearinghousing (ACH) transactions through automotive data processing system 100to purchase the vehicle from the dealership.

Turning briefly to the various other entities in the topology FIG. 1,dealers may use a dealer management system (“DMS”) 122 to track orotherwise manage sales, finance, parts, service, inventory and backoffice administration needs. Since many DMS 122 are Active Server Pages(ASP) based, data may be obtained directly from a DMS 122 with a “key”(for example, an ID and Password with set permissions within the DMS122) that enables data to be retrieved from the DMS 122. Many dealersmay also have one or more web sites which may be accessed over network105, where inventory and pricing data may be presented on those websites.

Inventory systems 124 may be systems of, for example, one or moreinventory polling companies, inventory management companies or listingaggregators which may obtain and store inventory data from one or moreof dealers (for example, obtaining such data from DMS 122). Inventorypolling companies are typically commissioned by the dealer to pull datafrom a DMS 122 and format the data for use on websites and by othersystems. Inventory systems 124 may provide information on inventoryvehicles that is used in the ranking of the vehicles when they arepresented to a consumer, such as prices of the vehicles and locations ofthe vehicles.

DMV systems 126 may collectively include systems for any type ofgovernment entity to which a user provides data related to a vehicle.For example, when a user purchases a vehicle it must be registered withthe state (for example, DMV, Secretary of State, etc.) for tax andtitling purposes. This data typically includes vehicle features (forexample, model year, make, model, mileage, etc.) and sales transactionprices for tax purposes. Additionally, DMVs may maintain tax records ofused vehicle transactions, inspection, mileages, etc.).

Information provider systems 120 may be systems of entities that provideinformation used in approving a user or purchase. Examples ofinformation provider systems 120 may include computer systems controlledby credit bureaus, fraud and ID vendors, vehicle data vendors orfinancial institutions. A financial institution may be any entity suchas a bank, savings and loan, credit union, etc. that provides any typeof financial services to a participant involved in the purchase of avehicle. Information provider systems 120 may comprise any number ofother various sources accessible over network 105, which may provideother types of desired data, for example, data used in identityverification, fraud detection, credit checks, credit risk predictions,income predictions, affordability determinations, residual valuedeterminations or other processes.

Automotive data processing system 100 utilizes interfaces configured to,for example, receive and respond to queries from users at clientcomputing devices 110, interface with information provider systems 120,DMS 122, inventory systems 124 and DMV systems 126, obtain data from orprovide data obtained or determined by automotive data processing system100 to any of information provider systems 120, DMS 122, inventorysystems 124, DMV systems 126. It will be understood that the particularinterface utilized in a given context may depend on the functionalitybeing implemented by automotive data processing system 100, the type ofnetwork utilized to communicate with any particular entity, the type ofdata to be obtained or presented, the time interval at which data isobtained from the entities, the types of systems utilized at the variousentities, etc. Thus, these interfaces may include, for example, webpages, web services, a data entry or database application to which datacan be entered or otherwise accessed by an operator, APIs, libraries orother type of interface which it is desired to utilize in a particularcontext.

Client computing devices 110, 111 may comprise one or more computersystems with central processing units executing instructions embodied onone or more computer readable media where the instructions areconfigured to interface with automotive data processing system 100. Aclient computing device 110, 111 may comprise, for example, a desktop,laptop, smart phone or other device. According to one embodiment, aclient computing device 110 is a mobile device that has a touchscreendisplay and relies on a virtual keyboard for consumer data input. Clientapplication 114 may be a mobile application (“mobile app”) that runs ina mobile operating system (e.g., Android OS, iOS), and is specificallyconfigured to interface with automotive data processing system 100 togenerate application pages for display to a consumer. In anotherembodiment, the client application 114 may be a web browser on a desktopcomputer or mobile device. A client computing device 111 may run anapplication through which a dealer portal can be accessed.

In accordance with one embodiment, a consumer can utilize clientapplication 114 to register with automotive data processing system 100,view inventory, select a vehicle, apply for financing, review documentsand finalize a sales transaction through a low friction mobile apprunning on a smart phone. Client application 114 can be configured withan interface module 115 to communicate data to/from automotive dataprocessing system 100 and generate a user interface for inputting one ormore pieces of information or displaying information received fromautomotive data processing system 100. In some embodiments, theapplication 114 may comprise a set of application pages through whichapplication 114 collects information from the consumer or which clientapplication 114 populates with data provided via an interface.Application 114 may collect information that is manually input by theconsumer so that it can be processed by automotive data processingsystem 100 with other information associated with the consumer. Thisinformation can be used to determine, for example, the consumer'squalification for a vehicle purchase, financing options available to theconsumer, or pricing for particular vehicles. Application 114 may alsocollect automatically information associated with the consumer's viewsof displayed vehicles and identification of particular vehicles asfavorites or subscribed vehicles. This information may be used to tunethe weights that are applied to signals input to a ranking engine thatdetermines an order in which vehicles are displayed to the consumer.

Vehicle data application 150 can comprise a set of processing modules toprocess obtained data or processed data to generate further processeddata. Different combinations of hardware, software, and/or firmware maybe provided to enable interconnection between different modules of thesystem to provide for the obtaining of input information, processing ofinformation and generating outputs.

In the embodiment of FIG. 1, vehicle data application 150 includes apricing module 156 which contains a demand model 152. Demand model 152uses historical transaction data 134 stored in data store 130 todetermine the payments for a consumer having a particular profile thatwill be likely to result in a completed purchase transaction. Pricingmodule 156 may also contain a cashflow module that uses contract records132 and information on customers' performance on those contracts 133.The cashflow model may take input payment information from demand model152 and information on the desired return for a transaction, from whichit can determine an acquisition price for particular types of vehicles.This acquisition price may then be compared to prices set by sellers forinventory vehicles 131 in order to determine which of these vehicles ispriced to meet the return requirement. A list of qualified vehicles 135for the consumer profile (vehicles that are priced at or below theacquisition price for that type of vehicle) can be stored in data store130 for quick retrieval when a consumer uses the system.

Vehicle data application 150 may also include various other moduleswhich are not described in detail herein. These modules may include, forexample, dealer interaction modules, user interaction modules, inventorymodules, order modules, financing modules, document modules, and variousother modules that may be necessary or desirable to perform thefunctions of the vehicle data application.

Referring to FIGS. 2 and 3, diagrams illustrating the operation of anautomotive data processing system at a high level in accordance with oneembodiment are shown. As depicted in these figures, a consumer profile210 and a vehicle type 220 are provided to a demand model 230 (step310). The demand model is derived from historical transaction data thatidentifies purchase transactions. The historical transaction data mayinclude data collected by the automotive data processing system withrespect to consumers that use the system, as well as data that iscollected by other entities and is then transferred to the automotivedata processing system.

Each of the transaction records has associated consumer information,vehicle type information, and payment information. This information isused by the automotive data processing system to determine the paymentlevels at which consumers having particular profiles are likely tocomplete purchase transactions for the identified types of vehicles andto generate a corresponding demand model. Demand model 230 is designedto receive the consumer profile 210 and vehicle type 220 as inputs,process these inputs, and provide the corresponding payment 240 as anoutput (step 320). It should be noted that the payment isconsumer-facing and is generated without regard to a specific vehiclethat is being offered for sale or lease by a particular seller, or anycosts that may be associated with selling or leasing a vehicle.

The payment 240 that is produced by the demand model for the identifiedconsumer profile and vehicle type may then itself be provided as aninput to a cash flow model (step 330). A desired return may also beinput to the cash flow model. The cash flow model may be derived fromhistorical contract performance data which is collected by the system.This data can be analyzed to determine the costs associated withtransactions involving particular types of vehicles. The cash flow modeldetermines, based upon the input return information and the paymentinformation 240 from demand model 230 a maximum acquisition price thatis necessary to provide the desired return for the particular type ofvehicle at the payment level indicated by the demand model. Theacquisition price, similar to the customer-facing payment, isindependent of any particular vehicle that may be available for sale onthe system.

The pricing module implemented in the automotive data processing systemis a function

which can be used to find a consumer facing price {tilde over (m)} for agiven consumer profile that will achieve goals related to fulfillingsome element of demand. In terms of the information signature:

: user attributes,

,vehicle attributes,

;target demand,{tilde over (d)}→consumer facing price,{tilde over (m)}

would have the functional form:

: {tilde over (m)} _({tilde over (d)})(

,

)

For the purposes of this disclosure, bars are used over variables toindicate that the value is set by a policy or the downstream effect of avalue set by policy. An arrow symbol over a variable indicates that thevariable represents a potentially multi-dimensional vector quantity.

User attributes can include, but are not limited to, attributes fromthings such as income, FICO score, or other items that may be found incredit bureau reports. The user attributes may be distilled into asingle score which reflects a consumer's ability to make payments on avehicle. Attributes such as the region in which the customer is shoppingmay be included, since such attributes may affect the consumer's vehiclepreferences.

Vehicle attributes may include intrinsic characteristics such as themake, model, mileage, color, year, MSRP or condition of the vehicle. Thevehicle attributes could also include, in a dynamic pricing context,attributes related to the historical performance of a specific vehiclewithin the automotive data processing system. For instance, the vehicleattributes may include the click-through rate on a vehicle relative to apredicted quantity of that vehicle (e.g., a quantity of vehicles of thesame make, model and year), or the length of time the vehicle has beenavailable in the system. The vehicle attributes typically would notinclude variables which would not be consumer-facing, and consequentlywould not affect or reflect consumer demand. For example, the cost atwhich a vehicle is being offered by a seller to the operator of theautomotive data processing system would not reflect consumer demand andwould not be included in the vehicle attributes.

The target demand, {tilde over (d)}, may be selected from any number ofpotential measures of demand. In one embodiment, a conditionalconversion probability is used as the measure of target demand. Theconditional conversion probability is the target probability that aconsumer with attributes

, having encountered an offer for a particular vehicle through a searchfeature of the automotive data processing system, will decide totransact on that vehicle. In alternative embodiments, other measures ofdemand may be used. For example, {tilde over (d)} could be determined bya target probability that a vehicle which has been available toconsumers in the automotive data processing system for two weeks hasbeen transacted on by a consumer with attributes

. This may be referred to as the vehicle velocity. In anotheralternative embodiment, a target click-through rate when the vehicle isdisplayed to a user with attributes

may be used as a measure of demand.

This measure of demand is referred to as a demand model not only becauseit relates generally to consumer demand, but also in the case of theconditional conversion probability because it refers to a prediction ofthe quantity of a specific car demanded by a specific consumer profileat a given price. As noted above, however, using granular informationabout user behavior within the automotive data processing system, thetarget demand could refer to the relationship between price and otheroutcomes besides quantity.

Referring to FIG. 4, a flow diagram illustrating a method for generatinga demand model in accordance with some embodiments is shown. IN thismethod, historical transaction data is collected or obtained by theautomotive data processing system (410). As noted above, the data maycomprise historical contract performance data that is collected by theautomotive data processing system. Alternatively, the system may obtaindata from external sources that have collected transaction data fromsources other than the automotive data processing system.

The historical transaction data in this embodiment is segregated intosubsets, each of which corresponds to a particular user group and aparticular vehicle type (420). Each of the subsets of data is thenanalyzed to determine the payment level associated with the subset ofdata (430). In alternative embodiments, the data may be processedwithout first segregating the data into subsets. In this case, the usergroup and vehicle type corresponding to each of the data records istracked so that the payments corresponding to each of the records can beanalyzed with respect to the corresponding user group and vehicle type.

Based on the analysis of the historical transaction data, the automotivedata processing system generates a demand model which defines aconsumer-facing payment level that is associated with the different usergroups and vehicle types (440). More specifically, for each of a definedset of consumer groups and vehicle types, the demand model defines acorresponding payment at which a consumer in a particular group can beexpected, with a particular level of confidence, to complete atransaction on a vehicle of a given type. The demand model may be basedon various different potential measures of consumer demand, such as aprobability of conversion of a transaction, a probability that a vehiclewill be transacted upon within a defined time period, or a targetclick-through rate. When the demand model has been defined, the model isstored (450) so that the pricing module of the automotive dataprocessing system can access the model and use the model to determine aconsumer-facing payment corresponding to a given consumer profile andvehicle type.

It should be noted that, although the exemplary method of FIG. 4 uses astratified approach that stratifies users into discrete groups, thehistorical transaction data may also be analyzed in a more continuousfashion that can be used to model demand for individual users ratherthan groups or classifications of users.

The pricing module is powered b a machine learning engine that functionsas a predictive demand model,

, where the relevant demand-based outcome is modeled as

:

,

,m→d,

where d is now an estimated demand rather than a target demand.

The descriptions of the examples of estimated demand d would be the sameas those of the corresponding targeted demand d.

would have the form

:d(m,

,

)

The model,

, is trained on the automotive data processing system's own historicaldata. If, as in the examples of demand above, the outcomes areprobabilistic and binary, then a logistic model could be used:

${{d\left( {m,\overset{\rightharpoonup}{U},\overset{\rightharpoonup}{V}} \right)} = \frac{1}{1 + {\exp\left( {\beta_{0} + {\beta_{m} \cdot m} + {{\overset{\rightarrow}{\beta}}_{U} \cdot \overset{\rightharpoonup}{U}} + {{\overset{\rightarrow}{\beta}}_{V} \cdot \overset{\rightharpoonup}{V}} + {{\overset{\rightarrow}{\beta}}_{\overset{\rightharpoonup}{U} \otimes \overset{\rightharpoonup}{V}} \cdot \left( {\overset{\rightharpoonup}{U} \otimes \overset{\rightharpoonup}{V}} \right)}} \right)}}},$

where ⊗ represents the Kronecker product.

In an alternative example, if a stratification approach were to be takenfor some of the variables, such as by categorizing consumers intogroups, then the model could have the form:

${d\left( {m,\overset{\rightharpoonup}{U},\overset{\rightharpoonup}{V}} \right)} = \left\{ \begin{matrix}\frac{1}{1 + {\exp\left( {\beta_{0,1} + {\beta_{m,1} \cdot m} + {{\overset{\rightarrow}{\beta}}_{V,1} \cdot \overset{\rightharpoonup}{V}}} \right)}} & {\overset{\rightharpoonup}{U}\mspace{14mu}{in}\mspace{14mu}{Group}\mspace{14mu} 1} \\\frac{1}{1 + {\exp\left( {\beta_{0,2} + {\beta_{m,2} \cdot m} + {{\overset{\rightarrow}{\beta}}_{V,2} \cdot \overset{\rightharpoonup}{V}}} \right)}} & {\overset{\rightharpoonup}{U}\mspace{14mu}{in}\mspace{14mu}{Group}\mspace{14mu} 2} \\\frac{1}{1 + {\exp\left( {\beta_{0,3} + {\beta_{m,3} \cdot m} + {{\overset{\rightarrow}{\beta}}_{V,3} \cdot \overset{\rightharpoonup}{V}}} \right)}} & {\overset{\rightharpoonup}{U}\mspace{14mu}{in}\mspace{14mu}{Group}\mspace{14mu} 3}\end{matrix} \right.$

Stratification could be performed on different car attributes as well.

The variables may be encoded in various ways, mathematically, but inthis sense there is an equivalence between stratification of a model ona variable and inclusion of that variable in the functional form. Ineither example, model training would be performed to find the optimalvalues of β to minimize some loss function,

, which is a measure of how much the predictions of the system's modeldeviate from the true outcomes of the training data. An example of sucha loss function could be the log-loss.

The pricing module

could then be implemented by

{tilde over (m)}(

,

)≡m, such that d(m,

,

)≡{tilde over (d)}.

This is done in one embodiment by numerically solving the function d forfixed

and

for m so that d is equal to {tilde over (d)} to within some tolerance.If the model uses the simple logistic model from above, then thefunction of the pricing module would be given by the closed formfunction:

${{\overset{\_}{m}}_{\overset{\_}{d}}\left( {\overset{\rightharpoonup}{U},\overset{\rightharpoonup}{V}} \right)} = \frac{{\ln\left( \frac{1 - d}{d} \right)} - \left( {\beta_{0} + {{\overset{\rightarrow}{\beta}}_{U} \cdot \overset{\rightharpoonup}{U}} + {{\overset{\rightarrow}{\beta}}_{V} \cdot \overset{\rightharpoonup}{V}} + {{\overset{\rightarrow}{\beta}}_{\overset{\rightharpoonup}{U} \otimes \overset{\rightharpoonup}{V}} \cdot \left( {\overset{\rightharpoonup}{U} \otimes \overset{\rightharpoonup}{V}} \right)}} \right)}{\beta_{m}}$

A closed form, however, is not generally available.

In practice, for computational efficiency, the results of the pricingmodule may be pre-computed for each vehicle for a set of user groups andtheir archetypal users: {

_(i)}, where i indicates the group of the archetypal users. Example ofgroups and their archetypal users could be, for example:

-   -   Group: “high payment performance customers in Tennessee”;        Archetypal User:        _(high,TN)=(FICO=630, Market=Nashville)    -   Group: “low payment performance customers in Los Angeles”        Archetypal User:        _(low,LA)=(FICO=520, Market=Los Angeles)

The price encountered by a user of the app would be the result ofsorting the customer into groups using a grouping function,

g(

)=i

This function determines to which group a user belongs, and displays thepre-computed price based on the archetypal member of that group:

{tilde over (m)} _({tilde over (d)})(

,

)→{tilde over (m)} _({tilde over (d)})(

_(x()

₎,

)

This is noted mainly to clarify that if a specific stratificationstrategy was used in the function there is no need for those strata tomatch the customer groups for matching to the archetypal users. Forexample, in one embodiment, the function d accepts a continuous valuefor FICO score, without stratification, but the pricing module may stillgroup consumers into three discrete ranges of FICO, where all consumerswithin the group are priced according to an archetypal user with themean FICO score of that group.

As noted above, the payment generated by the pricing module using thedemand model may be provided with a desired return to the cash flowmodel to generate a maximum acquisition price for a vehicle.

The target price output by the demand model corresponding to theidentified consumer profile and vehicle type is provided as an input tothe cash flow model. The cash flow model is designed to determine thecash flow that is generated by a transaction for a particular type ofvehicle at a given price. In one embodiment, the vehicle data systemcollects information relating to all contracts for vehicle purchasesthat are made using the system. This information is then used to developthe cash flow model. The collected contract information is used todetermine, for a given vehicle type and at a given price, theprobabilities that a consumer will maintain the contract, return thevehicle, or default on the contract.

In one embodiment, the cash flow model is developed using a databasethat is created with attributes which are known at the point oforigination and which might potentially drive the rate of default orreturn on a contract (e.g., FICO score, start payment, regular payment,vehicle year make model miles, vehicle value, origination location,origination channel (rideshare/consumer), etc.). The status of the loanat the beginning and the end of each contract period (defaulted,returned as agreed, actively paying) is also included.

The database contains a row for every contract for every due date frominception of the contract. For example, Rideshare contracts that involveweekly payments have one row per week for every account (e.g., 52 rowsfor a 1 year old account), while consumer loans which are due formonthly payments have 12 rows of status results for a year. In bothcases, the origination attributes are repeated on every row. Thedatabase may have hundreds of thousands of rows (records).

An analysis is performed on the records in the database to predict thelikelihood of return or default for any configuration of attributesknown at origination, for any period in the life of the subscription.The output is a formula that predicts the likelihood of default, return,or continued payment for every invoice period (typically for 36 monthsin the case of rideshare and 48 months in the case of consumer). In thisembodiment, it is assumed that after the full length of the loan period,the customers will return their vehicles.

An example of such a formula may be

g(Σ_(i=1) ^(N) f(x _(i)β)),

where N is the number of feature attributes in the said model, x is anattribute, β is some estimated coefficient and g is a functional form,and f is also a functional form such as a linear combination.

Based upon these probabilities, the expected net gross cash flow from acontract for this type of vehicle at this price can be determined. Theformula for the probabilities of default, return, or continued paymentis then put into a model that includes business costs, such as cost ofcapital, marketing, origination costs, servicing costs, depreciation,and liquidation costs. When these costs are added to the cost ofacquisition of the vehicle from the dealer, the result is a gross cashflow expectation for the vehicle.

When the details of any of the previously originated vehicles are inputto the model, the model might predict that, on average, the actualpayment results in an expected return that is very high, or evenpossibly negative. Thousands of deals are therefore loaded, one by one,into the model, and are solved for a target return by adjusting theregular payment, saving the regular payment, and then using statisticson the deals with the ideal regular payment (the one that results in thedesired return) to develop a general formula using the known originationattributes as inputs to drive a payment appropriate for a deal on aparticular type of vehicle.

In one embodiment, a separate filter (not included in the model) is usedto exclude certain vehicles which are not good fits with the consumer.For example, the vehicles may be excluded because the payment is notcompetitive, or because the vehicle is a type that is usually notpreferred by the consumer (e.g., pickup trucks are not usually preferredby uber drivers).

In one embodiment, the acquisition price generated by the cashflow modelis provided to a comparison engine that receives inventory recordscorresponding to available inventory vehicles that are available to theautomotive data processing system. Each of the vehicle inventory recordsidentifies the corresponding purchase price for the vehicle, which isset by the seller of the vehicle. The comparison engine compares thepurchase price for each inventory vehicle (of the type associated withthe acquisition price) with the acquisition price and either qualifiesor disqualifies the vehicle based upon the comparison. If the purchaseprice is less than or equal to the acquisition price, the vehicle isqualified, and if the purchase price is greater than the acquisitionprice, the vehicle is disqualified. Qualified vehicles are then madeavailable to be displayed to consumers through the vehicle dataapplication, while disqualified vehicles are blocked from beingdisplayed to consumers.

As noted above, the acquisition price is associated with a particularconsumer profile. As it is determined whether each vehicle is qualifiedor not, qualified vehicles are added to a list of qualified vehicles forthe corresponding consumer profile, while disqualified vehicles are not.This same process is repeated for each of a set of possible consumerprofiles so that multiple lists of qualified vehicles are stored by thesystem, with each list being associated with a corresponding consumerprofile. Then, when a specific consumer interacts with the system, oneof the consumer profiles which is associated with the consumer isidentified and the corresponding list of qualified vehicles isretrieved, and the list is used to identify the vehicles that arequalified for the specific consumer. Since only vehicles that haveacquisition prices at or below the acquisition price are qualified fordisplay to the consumer through the application, any purchase or leasetransactions that are completed necessarily involve vehicles that arepriced at a level sufficient to provide the desired return for thesystem operator.

Referring to FIG. 5, the use of the qualified vehicle list in accordancewith some embodiments is shown. As depicted in this figure, a consumerfirst logs on to a client application which interacts with the vehicledata application (510). The vehicle data application identifies theconsumer profile that is associated with the consumer (520) and thenretrieves the corresponding list of qualified vehicles (which wasdetermined based in part upon the payment determined by the demandmodel) from a data store (530). As noted above, each of the vehicles inthe list has been compared to an acquisition price associated with theconsumer profile, so it is not necessary to separately qualify vehiclesfor each consumer, or to expend the time and computational resourcesnecessary to do so when the consumer logs in. After retrieving the listof qualified vehicles, the consumer may interact with the vehicle dataapplication, such as by submitting vehicle queries or browsing vehiclelistings (540). The automotive data processing system then generates adisplay which includes one or more of the qualified vehicles andpresents the display on a client device (550). Because the vehicles thatare displayed to the consumer responsive to these queries or in thecourse of browsing are selected from the qualified vehicles that werepreviously identified by the vehicle data application, it is assuredthat any transaction completed by the consumer will provide the returndesired by the system operator.

It should be noted that the sellers of the vehicles may be provided withthe ability to view the vehicles that are displayed to users havingparticular consumer profiles, and may therefore be able to determinewhether or not particular vehicles that they have made available forpurchase or lease through the vehicle data system are qualified fordisplay. If a seller determines that a particular vehicle is not beingdisplayed to consumers having a particular profile, the seller maychange the purchase price of the vehicle in order to ensure that thevehicle is qualified. In one embodiment, the seller may use a clientapplication which includes a tool such as a slider bar to adjust theprice to a level which is at or below the acquisition pricecorresponding to that type of vehicle, thereby allowing the vehicle tobe qualified and displayed to consumers.

Embodiments of the automotive data processing system may be implementedin a variety of different computing systems. FIG. 6 depicts adiagrammatic representation of a distributed network computingenvironment where embodiments disclosed can be implemented. In theexample illustrated, network computing environment 600 includes network604 that can be bi-directionally coupled to a client computing device614, a server system 616 and one or more third party system 617. Serversystem 616 can be bi-directionally coupled to data store 618. Network604 may represent a combination of wired and wireless networks thatnetwork computing environment 600 may utilize for various types ofnetwork communications known to those skilled in the art.

For the purpose of illustration, a single system is shown for each ofclient computing device 614 and server system 616. However, a pluralityof computers may be interconnected to each other over network 604. Forexample, a plurality client computing devices 614 and server systems 616may be coupled to network 604.

Client computer device 614 can include central processing unit (“CPU”)620, read-only memory (“ROM”) 622, random access memory (“RAM”) 624,hard drive (“HD”) or storage memory 626, and input/output device(s)(“I/O”) 628. I/O 628 can include a keyboard, monitor, printer,electronic pointing device (e.g., mouse, trackball, stylus, etc.), orthe like. In one embodiment I/O 628 comprises a touch screen interfaceand a virtual keyboard. Client computer device 614 may implementsoftware instructions to provide a client application configured tocommunicate with an automotive data processing system. Likewise, serversystem 616 may include CPU 660, ROM 662, RAM 664, HD 666, and I/O 668.Server system 616 may implement software instructions to implement avariety of services for an automotive data processing system. Theseservices may utilize data stored in data store 618 and obtain data fromthird party systems 617. Many other alternative configurations arepossible and known to skilled artisans.

Each of the computers in FIG. 6 may have more than one CPU, ROM, RAM,HD, I/O, or other hardware components. For the sake of brevity, eachcomputer is illustrated as having one of each of the hardwarecomponents, even if more than one is used. Each of computers 614 and 616is an example of a data processing system. ROM 622 and 662; RAM 624 and664; HD 626, and 666; and data store 618 can include media that can beread by CPU 620 or 660. Therefore, these types of memories includenon-transitory computer-readable storage media. These memories may beinternal or external to computers 614 or 616.

Portions of the methods described herein may be implemented in suitablesoftware code that may reside within ROM 622 or 662; RAM 624 or 664; orHD 626 or 666. The instructions may be stored as software code elementson a data storage array, magnetic tape, floppy diskette, optical storagedevice, or other appropriate data processing system readable medium orstorage device.

While the foregoing embodiments were provided primarily in the contextof an automotive data processing system, it will be appreciated thatembodiments described herein may be applied to other assets (e.g.,real-estate, boats, etc.). In particular, embodiments may be adapted forassets for which depreciation can be modeled. Moreover, those skilled inthe relevant art will appreciate that the invention can be implementedor practiced with other computer system configurations, includingwithout limitation multi-processor systems, network devices,mini-computers, mainframe computers, data processors, and the like. Theinvention can be embodied in a computer or data processor that isspecifically programmed, configured, or constructed to perform thefunctions described in detail herein. The invention can also be employedin distributed computing environments, where tasks or modules areperformed by remote processing devices, which are linked through acommunications network such as a local area network (LAN), wide areanetwork (WAN), and/or the Internet. In a distributed computingenvironment, program modules or subroutines may be located in both localand remote memory storage devices. These program modules or subroutinesmay, for example, be stored or distributed on computer-readable media,including magnetic and optically readable and removable computer discs,stored as firmware in chips, as well as distributed electronically overthe Internet or over other networks (including wireless networks).

ROM, RAM, and HD are computer memories for storing computer-executableinstructions executable by the CPU or capable of being compiled orinterpreted to be executable by the CPU. Suitable computer-executableinstructions may reside on a computer readable medium (e.g., ROM, RAM,and/or HD), hardware circuitry or the like, or any combination thereof.Within this disclosure, the term “computer readable medium” is notlimited to ROM, RAM, and HD and can include any type of data storagemedium that can be read by a processor. Examples of computer-readablestorage media can include, but are not limited to, volatile andnon-volatile computer memories and storage devices such as random accessmemories, read-only memories, hard drives, data cartridges, directaccess storage device arrays, magnetic tapes, floppy diskettes, flashmemory drives, optical data storage devices, compact-disc read-onlymemories, and other appropriate computer memories and data storagedevices. Thus, a computer-readable medium may refer to a data cartridge,a data backup magnetic tape, a floppy diskette, a flash memory drive, anoptical data storage drive, a CD-ROM, ROM, RAM, HD, or the like.

Any suitable programming language can be used to implement the routines,methods or programs of embodiments of the invention described herein.Other software/hardware/network architectures may be used. For example,the functions of the disclosed embodiments may be implemented on onecomputer or shared/distributed among two or more computers in or acrossa network. Communications between computers implementing embodiments canbe accomplished using any electronic, optical, radio frequency signals,or other suitable methods and tools of communication in compliance withknown network protocols.

Different programming techniques can be employed such as procedural orobject oriented. Any particular routine can execute on a single computerprocessing device or multiple computer processing devices, a singlecomputer processor or multiple computer processors. Data may be storedin a single storage medium or distributed through multiple storagemedia, and may reside in a single database or multiple databases (orother data storage techniques). Although the steps, operations, orcomputations may be presented in a specific order, this order may bechanged in different embodiments. In some embodiments, to the extentmultiple steps are shown as sequential in this specification, somecombination of such steps in alternative embodiments may be performed atthe same time. The sequence of operations described herein can beinterrupted, suspended, or otherwise controlled by another process, suchas an operating system, kernel, etc. The routines can operate in anoperating system environment or as stand-alone routines. Functions,routines, methods, steps and operations described herein can beperformed in hardware, software, firmware or any combination thereof.

Embodiments described herein can be implemented in the form of controllogic in software or hardware or a combination of both. The controllogic may be stored in an information storage medium, such as acomputer-readable medium, as a plurality of instructions adapted todirect an information processing device to perform a set of stepsdisclosed in the various embodiments. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the invention.

It is also within the spirit and scope of the invention to implement insoftware programming or code an of the steps, operations, methods,routines or portions thereof described herein, where such softwareprogramming or code can be stored in a computer-readable medium and canbe operated on by a processor to permit a computer to perform any of thesteps, operations, methods, routines or portions thereof describedherein. The invention may be implemented by using software programmingor code in one or more digital computers, by using application specificintegrated circuits, programmable logic devices, field programmable gatearrays, optical, chemical, biological, quantum or nanoengineeredsystems, components and mechanisms may be used. The functions of theinvention can be achieved by distributed or networked systems.Communication or transfer (or otherwise moving from one place toanother) of data may be wired, wireless, or by any other means.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,article, or apparatus that comprises a list of elements is notnecessarily limited only those elements but may include other elementsnot expressly listed or inherent to such process, article, or apparatus.Further, unless expressly stated to the contrary, “or” refers to aninclusive or and not to an exclusive or. For example, a condition “A orB” is satisfied by any one of the following: A is true (or present) andB is false (or not present), A is false (or not present) and B is true(or present), and both A and B are true (or present).

To the extent particular values are provided in any example embodimentsin the description, such values are provided by way of example and notlimitation. Moreover, while in some embodiments rules may use hardcodedvalues, in other embodiments rules may use flexible values. In oneembodiment, one or more of the values may be specified in a registry,allowing the value(s) to be easily updated without changing the code.The values can be changed, for example, in response to analyzing systemperformance.

Additionally, any examples or illustrations given herein are not to beregarded in any way as restrictions on, limits to, or expressdefinitions of, any term or terms with which they are utilized. Instead,these examples or illustrations are to be regarded as being describedwith respect to one particular embodiment and as illustrative only.Those of ordinary skill in the art will appreciate that any term orterms with which these examples or illustrations are utilized willencompass other embodiments which may or may not be given therewith orelsewhere in the specification and all such embodiments are intended tobe included within the scope of that term or terms. Language designatingsuch nonlimiting examples and illustrations includes, but is not limitedto: “for example,” “for instance,” “e.g.,” “in one embodiment.”

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any component(s) thatmay cause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as a critical, required, or essentialfeature or component.

What is claimed is:
 1. A method implemented in an automotive dataprocessing system, the method comprising: receiving, by a pricing moduleof an automotive data processing system, data identifying a first one ofa plurality of consumer groups and a first one of a plurality of vehicletypes; accessing, by the pricing module of the automotive dataprocessing system, a demand model of a machine learning engine which isconfigured to maintain a set of weights @ that are included in apredictive demand function of the demand model, wherein the machinelearning engine is configured to adjust the weights to minimize a lossfunction which measures deviation of demand estimated by the predictivedemand function from actual demand indicated by a set of historicaltransaction data, wherein the demand model defines, for each of aplurality of combinations of the plurality of consumer groups and theplurality of vehicle types, a corresponding payment; and generating, bythe pricing module of the automotive data processing system, a firstpayment corresponding to the first one of the plurality of consumergroups and the first one of the plurality of vehicle types.
 2. Themethod of claim 1, wherein the weights include a price weight βm, aconsumer attribute weight β_(U), and a vehicle attribute weight β_(V).3. The method of claim 2, wherein the consumer attribute weight β_(U),and the vehicle attribute weight β_(V) comprise vector weights.
 4. Themethod of claim 1, wherein the predictive demand function comprises afunction d(m,

,

), where${{d\left( {m,\overset{\rightharpoonup}{U},\overset{\rightharpoonup}{V}} \right)} = \frac{1}{1 + {\exp\left( {\beta_{0} + {\beta_{m} \cdot m} + {{\overset{\rightarrow}{\beta}}_{U} \cdot \overset{\rightharpoonup}{U}} + {{\overset{\rightarrow}{\beta}}_{V} \cdot \overset{\rightharpoonup}{V}} + {{\overset{\rightarrow}{\beta}}_{\overset{\rightharpoonup}{U} \otimes \overset{\rightharpoonup}{V}} \cdot \left( {\overset{\rightharpoonup}{U} \otimes \overset{\rightharpoonup}{V}} \right)}} \right)}}},$and where ⊗ represents the Kronecker product, m represents a consumerfacing price,

represents a set of consumer attributes, and

represents a set of vehicle attributes.
 5. The method of claim 1,wherein the predictive demand function comprises a stratified functiond(m,

,

), where${d\left( {m,\overset{\rightharpoonup}{U},\overset{\rightharpoonup}{V}} \right)} = \left\{ {\begin{matrix}\frac{1}{1 + {\exp\left( {\beta_{0,1} + {\beta_{m,1} \cdot m} + {{\overset{\rightarrow}{\beta}}_{V,1} \cdot \overset{\rightharpoonup}{V}}} \right)}} & {\overset{\rightharpoonup}{U}\mspace{14mu}{in}\mspace{14mu}{Group}\mspace{14mu} 1} \\\frac{1}{1 + {\exp\left( {\beta_{0,2} + {\beta_{m,2} \cdot m} + {{\overset{\rightarrow}{\beta}}_{V,2} \cdot \overset{\rightharpoonup}{V}}} \right)}} & {\overset{\rightharpoonup}{U}\mspace{14mu}{in}\mspace{14mu}{Group}\mspace{14mu} 2} \\\frac{1}{1 + {\exp\left( {\beta_{0,3} + {\beta_{m,3} \cdot m} + {{\overset{\rightarrow}{\beta}}_{V,3} \cdot \overset{\rightharpoonup}{V}}} \right)}} & {\overset{\rightharpoonup}{U}\mspace{14mu}{in}\mspace{14mu}{Group}\mspace{14mu} 3}\end{matrix},} \right.$ and where m represents a consumer facing price,U represents a set of consumer attributes, and

represents a set of vehicle attributes.
 6. The method of claim 1,further comprising tracking activities of one or more users of theautomotive data processing system and storing data corresponding to theactivities of the one or more users, wherein the set of historicaltransaction data comprises the stored data corresponding to theactivities of the one or more users.
 7. The method of claim 1, whereinthe demand model measures a conditional conversion probability whichindicates a target probability that a consumer with consumer attributes

will transact on an offer for a particular vehicle having vehicleattributes

through a search function of the automotive data processing system. 8.The method of claim 1, wherein the demand model measures a vehiclevelocity probability which indicates a target probability that aconsumer with consumer attributes

will transact on an offer for a particular vehicle having vehicleattributes

through a search function of the automotive data processing systemwithin a predetermined time period from the particular vehicle becomingavailable through the automotive data processing system.
 9. The methodof claim 1, wherein the demand model measures a click-through rate whichindicates a rate at which consumers with consumer attributes

will select vehicles having vehicle attributes

through a viewing function of the automotive data processing system. 10.An automotive data processing system comprising: one or more processorscommunicatively coupled to one or more data storage devices, the one ormore processors coupled to a non-transitory computer-readable mediumthat stores instructions which are executable by the processor to causethe processor to execute an automotive data processing system which isconfigured to perform: receiving, by a pricing module of an automotivedata processing system, data identifying a first one of a plurality ofconsumer groups and a first one of a plurality of vehicle types;accessing, by the pricing module of the automotive data processingsystem, a demand model of a machine learning engine which is configuredto maintain a set of weights β that are included in a predictive demandfunction of the demand model, wherein the machine learning engine isconfigured to adjust the weights to minimize a loss function whichmeasures deviation of demand estimated by the predictive demand functionfrom actual demand indicated by a set of historical transaction data,wherein the demand model defines, for each of a plurality ofcombinations of the plurality of consumer groups and the plurality ofvehicle types, a corresponding payment; and generating, by the pricingmodule of the automotive data processing system, a first paymentcorresponding to the first one of the plurality of consumer groups andthe first one of the plurality of vehicle types.
 11. The automotive dataprocessing system of claim 10, wherein the weights include a priceweight β_(m), a consumer attribute weight β_(U), and a vehicle attributeweight β_(V), wherein the consumer attribute weight β_(U), and thevehicle attribute weight β_(V) comprise vector weights.
 12. Theautomotive data processing system of claim 10, further comprisingtracking activities of one or more users of the automotive dataprocessing system and storing data corresponding to the activities ofthe one or more users, wherein the set of historical transaction datacomprises the stored data corresponding to the activities of the one ormore users.
 13. The automotive data processing system of claim 10,wherein the demand model measures one or more of: a conditionalconversion probability which indicates a target probability that aconsumer with consumer attributes

will transact on an offer for a particular vehicle having vehicleattributes

through a search function of the automotive data processing system; avehicle velocity probability which indicates a target probability thatthe consumer with consumer attributes

will transact on the offer for the particular vehicle having vehicleattributes

within a predetermined time period from the particular vehicle becomingavailable through the automotive data processing system; and aclick-through rate which indicates a rate at which consumers withconsumer attributes

will select vehicles having vehicle attributes

through a viewing function of the automotive data processing system. 14.A computer program product for generating vehicle encodings, thecomputer program product comprising a non-transitory computer-readablemedium storing instructions executable by a processor to cause theprocessor to perform: receiving, by a pricing module of an automotivedata processing system, data identifying a first one of a plurality ofconsumer groups and a first one of a plurality of vehicle types;accessing, by the pricing module of the automotive data processingsystem, a demand model of a machine learning engine which is configuredto maintain a set of weights β that are included in a predictive demandfunction of the demand model, wherein the machine learning engine isconfigured to adjust the weights to minimize a loss function whichmeasures deviation of demand estimated by the predictive demand functionfrom actual demand indicated by a set of historical transaction data,wherein the demand model defines, for each of a plurality ofcombinations of the plurality of consumer groups and the plurality ofvehicle types, a corresponding payment; and generating, by the pricingmodule of the automotive data processing system, a first paymentcorresponding to the first one of the plurality of consumer groups andthe first one of the plurality of vehicle types.
 15. The computerprogram product of claim 14, wherein the weights include a price weightβ_(m), a consumer attribute weight β_(U), and a vehicle attribute weightβ_(V), wherein the consumer attribute weight β_(U), and the vehicleattribute weight β_(V) comprise vector weights.
 16. The computer programproduct of claim 14, further comprising tracking activities of one ormore users of the automotive data processing system and storing datacorresponding to the activities of the one or more users, wherein theset of historical transaction data comprises the stored datacorresponding to the activities of the one or more users.
 17. Thecomputer program product of claim 14, wherein the demand model measuresone or more of: a conditional conversion probability which indicates atarget probability that a consumer with consumer attributes

will transact on an offer for a particular vehicle having vehicleattributes

through a search function of the automotive data processing system; avehicle velocity probability which indicates a target probability thatthe consumer with consumer attributes

will transact on the offer for the particular vehicle having vehicleattributes

within a predetermined time period from the particular vehicle becomingavailable through the automotive data processing system; and aclick-through rate which indicates a rate at which consumers withconsumer attributes

will select vehicles having vehicle attributes

through a viewing function of the automotive data processing system.